1. Field of the Invention
The present invention relates to the field of computer programming, and more particularly to a technique for managing Enterprise JavaBeans.TM. which are being utilized by concurrent and/or nested transactions. This technique enables maintaining the integrity of the Enterprise JavaBeans.TM..
2. Description of the Related Art
"JavaBeans" is the name of a component architecture for use with the Java programming language. ("JavaBeans" and "Java" are trademarks of Sun Microsystems, Inc.) A JavaBean is the Java term for a "component", where a component is a reusable building block of application logic that a programmer can combine with other components to form an application program. "Enterprise JavaBeans" is a server component architecture which extends the JavaBeans architecture to the enterprise. "Enterprise" in this sense refers to an organization that uses computers in a networking environment, typically on a very large scale.
A Java programmer creates a Java application program by assembling components that provide the desired functionality for his application. A JavaBean may contain code for a relatively simple function such as displaying a button on a graphical user interface ("GUI"), but it may also contain quite complex code. An Enterprise JavaBean, or "EJB", is similar to a JavaBean, with several notable exceptions. JavaBeans are intended to execute locally, within the Java Virtual Machine ("JVM") on which a Java application is running. EJBs, on the other hand, are intended to execute on a server machine in a network, where they are remotely invoked by messages sent from a client machine's JVM. JavaBeans may provide code for visual objects, such as the GUI button discussed above; EJBs are always non-visual.
For an EJB, the executable business logic is stored within the entity bean. An EJB's business methods are invoked by sending a message to the EJB's wrapper, where a "wrapper" is the Java term for functionality required to adapt an EJB to its container, and a "container" is the Java terminology for the run-time environment in which an EJB (including the entity bean) is executed. The business method invocations are forwarded to the entity bean by the wrapper for execution. Thus, the wrapper is not always able to detect when an EJB has been modified. This differs from the approach of the related application filed Dec. 31, 1997, titled "Technique for Managing Objects which are the Target of Multiple Transactions in a Client/Server Environment", which is hereinafter referred to as "the related application", where the executable business logic is stored within the wrapper (referred to as a "shell" in the related application).
Both JavaBeans and EJBs differ from "pure" objects in object-oriented programming in that they have a required external interface. This interface is called the "properties" interface. Using this external interface, a development tool can interrogate the JavaBean or EJB, to determine what its component does and how its function is to be invoked by other components. The properties interface also enables developers to customize the behavior of components without having access to the source code. As a simple example, when the component contains code for displaying a button on a GUI, the developer may use a component property to specify the text that should be displayed on the button face.
In large-scale enterprise computing environments, a single server application may serve multiple concurrent client applications, each accessing an overlapping set of EJBs, while other server applications are also accessing the EJBs. See FIG. 1, which depicts a simple example of this situation. A collection of EJBs is stored in a data store, such as database 110. These stored EJBs may be accessed concurrently by one or more server application programs. Two server applications 120, 122 are shown in FIG. 1, but many more than two applications may share access to a data store, as is known in the art. (The collection of EJBs being accessed by the applications may reside on multiple data stores, although only one data store 110 has been shown in FIG. 1.) Each server application may have one or more clients that are executing the application at a given time. Server application 120 is shown in FIG. 1 as having two clients 130, 135, and server application 122 is shown as having three clients 140, 145, 150.
Many enterprise applications that reflect complex business processes require that users have the ability to navigate freely between different elements of the user interface. For example, the user may wish to have multiple windows for one application open on the display at the same time. Users of such applications have come to expect that they can switch from processing information in one window to processing information in a different window without having to take special precautions to ensure consistency of the data between the different windows. In particular, if the user makes changes to data values in one window, he does not expect to have to take steps to permanently store the changes in a data store before subsequently-opened windows for the same application can recognize the changed data.
The related application defines a technique for solving this problem for objects using a transactional approach, where the tasks a user (or application program) performs are organized into transactions. Using commonly-known industry terms, a transaction represents a logical group of changes to one or more objects that will be performed in an atomic manner (that is, either all operations within the transaction are performed, or none of them are performed). Using the transactional approach defined in this related application, all changes that the user wants to make to an object within the scope of a transaction are made first to an internal copy (called a "version") of the object, without actually updating the persistent, stored object itself. The user eventually decides whether to permanently commit the changes encompassed by the transaction, or whether to discard them. If the user chooses to commit, then the updated object in the version is copied to the persistent store. If the user chooses to discard (or "roll back") the changes, the persistent store is left unchanged.
The technique defined in this related application enables nested transactions to have views of an object that are completely independent from the views of other concurrent transactions. A nested transaction is one where the transaction is logically viewed as a tree, each subtree being either nested or flat. Nested transaction subtrees are internal nodes within the tree structure, and flat transactions are leaf nodes of the tree. The root of a transaction is called the "top-level transaction"; nodes below this top level are called "subtransactions". A transaction's predecessor node in the tree is called a "parent" and nodes below that transaction in the tree are called "child" nodes, using the terminology for tree structures that is commonly known in the computer programming art. Within the scope of a nested transaction, a subtransaction at any level may either commit its changes or roll them back. When a subtransaction commits its changes, the changed values are made accessible upward in the tree only to the parent node of this subtransaction. The change does not actually update the persistent store unless and until the top-level transaction is committed. Further, the changes are not visible to any siblings of the committed subtransaction, or to any nodes other than the parent (such as subtransactions that are siblings of this parent), until the changes propagate upward through the tree by commits at higher-level nodes. If a subtransaction rolls back, then the changes made by this subtransaction and all its children are discarded, without updating the persistent store.
The nature of the complex multi-user applications executed in an enterprise computing environment require that the EJBs being used in application deployment can be concurrently accessed, with consistent views of the EJBs being provided to each accessing application. The application or the application user must be able to commit or roll back the work that has been done from any view of the EJB, and from all views opened from that view in a nested fashion. Version 1.0, section 9.5 of the Enterprise JavaBeans specification ("Enterprise JavaBeans", dated Mar. 21, 1998, published by Sun Microsystems, Inc.) states that when an EJB is accessed concurrently from multiple transactions, the consistency of the EJB between the transactions will be handled automatically by functions that will provide isolation between transactions. The component that is to provide this isolation is the container. The EJB specification discusses two alternative methods with which a container might isolate transactions, but does not provide implementation details or guidelines for mechanisms that might be used. The two methods discussed therein are (1) serialized access to EJBs and (2) creating multiple instances of the EJB, one for each transaction in which the EJB is being accessed.
The inventors of the present invention believe that serialized access is an unacceptable solution for isolating EJBs among transactions, because a serious performance penalty is involved. Serialized access requires that the EJB be locked when a transaction accesses it, such that subsequent transactions must wait until the lock is released by the earlier transaction. Many typical enterprise applications will have transactions that span long periods of time, so that a lock by one application will likely result in corresponding delays while the subsequent applications must wait. Users of computer applications have come to expect nearly instantaneous response times from their applications. The delays that will potentially result from applications using serialized access are unlikely to be acceptable from a user perspective.
According to the second alternative method for container isolation described in the EJB specification, each transaction that accesses an EJB will have its own instance of the EJB, as stated above. The container activates a new instance of the EJB for each accessing transaction, and the underlying database in which the EJB is stored is expected to provide serialization among transactions during database access calls (without any transaction serialization requirements being placed upon the container), according to section 9.5 of the EJB specification. While this multiple instances approach avoids the performance penalties inherent in the serialized access approach, managing the instances is a very complex task. Placing the responsibility for transaction serialization of the instances on the database system addresses only the end result of the transaction--that is, making sure that multiple database transactions cannot make changes to one persistent EJB in an interleaved manner that would very likely lead to unpredictable results. A solution that enables changes to be accessible to views within a transaction, yet isolated appropriately among nested subtransactions within that transaction and isolated from other transactions within the same application, must then be provided by logic within the application itself. The solution in the related application for managing objects using transactions cannot be used to manage EJBs, because as discussed earlier, the logic for an EJB is stored in the bean and thus changes to the bean that are made by executing this logic are not automatically detectable by the EJB's container or its wrapper. Therefore, neither the container nor the wrapper knows when the EJB needs to be persisted (i.e. stored to the persistent store).
Accordingly, what is needed is a technique whereby transaction isolation for EJBs can be efficiently implemented using multiple instances, such that a particular EJB can be accessed from multiple concurrent and/or nested transactions while ensuring consistency among the transactions and among the nested subtransactions, and while permitting these concurrent and/or nested transactions to have completely independent views of the EJB. The present invention provides a technique for representing changes made by a transaction with a tree structure that is internally managed by the application program wherein the changes were made. Each transaction within an application has an independent version of the EJB, and thus an independent transaction tree where the changes made by that transaction are stored during the course of the transaction. Each subtransaction within a nested transaction may also have an independent view of the EJB, by storing that subtransactions' changes at an intermediate level within the tree. The present invention also provides a technique for merging multiple views within a nested transaction, and committing the merged result to the persistent data store.